well core information behave test development#230
Conversation
There was a problem hiding this comment.
Looks good! I really appreciate the TODO comments you left about the items that need to be added to the models/schemas/tests.
Am I returning longitude/latitude and easting/northing in a correct fashion? Should I call them point_gcs and point_pcs and then include metadata for the geographic and projected coordinate systems?
Regarding naming conventions, maybe point_wgs84 and point_utm? I think we decided that the coordinate transformations would occur in the schema.
|
The feature file says the the response should include |
I'm updating the feature file to specify the use of geojson for consistency in the app. |
| @@ -165,9 +215,13 @@ def step_impl(context): | |||
| 'the response should include a geometry object with type "Point" and coordinates array [longitude, latitude, elevation] in decimal degrees with datum WGS84' | |||
| ) | |||
| def step_impl(context): | |||
There was a problem hiding this comment.
there should be an assertion that the x and y are actually latitude and longitude. -90, 90, -180,180.
there should also be an assertion that the horizontal datum is WGS84
There was a problem hiding this comment.
I saw this after merging into our shared pre-staging branch. Here are asserts I can use:
assert context.water_well_data["current_location"]["crs"] == {
"type": "name",
"properties": {
"name": "EPSG:4326",
},
}
assert longitude >= -180 and longitude <= 180
assert latitude >= -90 and latitude <= 90From what I've read crs has been deprecated and is no longer used. GeoJSONs must be in WGS84. Because of this, is it worth having the crs field? Or should it just be assumed and the frontend will just know and display that as the horizontal datum? @chasetmartin do you want the string WGS84 in the response somehow?
There was a problem hiding this comment.
If the proper way to define it in geojson properties is EPSG:4326 that seems fine.
There was a problem hiding this comment.
I can put crs in there, but according to the specs all GeoJSONs have to be in WGS84
The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees.
Given that must be the case, should I still include crs? It has been used in the past, but is now deprecated.
There was a problem hiding this comment.
Ah I see what you're saying. If crs is deprecated in GeoJSON spec I don't think we should include it. But since we have horizontal_datum for UTM coords in their properties, I think we should have horizontal_datum within these properties that identifies WGS84, just to be explicit with the client.
There was a problem hiding this comment.
@jirhiker because all GeoJSONs use WGS84 and the coordinates are decimal degrees the feature file was updated to
# Location Information
# GeoJSON spec format RFC 7946 (Aug 2016) requires coordinates to be decimal degrees in WGS84
And the response should include location information in GeoJSON spec format RFC 7946
And the response should include a geometry object with type "Point" and coordinates array [longitude, latitude, elevation]
The note was included for documentation purposes
4 participants
Thoughts? Am I returning
longitude/latitudeandeasting/northingin a correct fashion? Should I call thempoint_gcsandpoint_pcsand then include metadata for the geographic and projected coordinate systems?